[ELK] ElasticSearch란? ELK란? 내부 구조, 장단점, RDB와 차이

ElasticSearch란?

Elasticsearch는 Apache Lucene기반의 Java 오픈 소스 분산 검색 엔진이다.

Elasticsearch를 통해 방대한 양의 데이터를 신속하게(거의 실시간) 저장, 검색, 분석을 수행할 수 있다.

Elasticsearch는 검색 엔진으로 단독으로 사용되기도 하며, ELK(Elasticsearch / Logstash / Kibana) 스택으로 사용되기도 한다.

 

이러한 Elasticsaerch는 대규모 로그 파일 관리나 실시간 검색 서비스 등과 같이 대용량 데이터를 빠르게 처리해야 하는 경우 유용하게 사용될 수 있다.

---

데이터 저장 방법 (RDBMS와 차이점)

• RDB는 정규화된 스키마에 따라 데이터를 구조화하지만, Elasticsearch는 JSON 문서 형태로 비정형 데이터도 저장하고 인덱싱할 수 있다.
• RDB는 Row를 기반으로 데이터를 저장하지만, Elasticsearch는 단어를 기반으로 데이터를 저장한다.
• Elasticsearch은 마치 NoSQL의 key-value DB와 같이 저장된다. 그렇기 때문에 Elasticsearch는 수정과 삭제가 많은 경우에는 많은 리소스가 소비될 수 있지만 검색 속도는 빠르다는 장점이 있다.

다음은 RDB와 Elasticsearch의 용어 차이에 대해 정리한 표이다.

---

Elasticsearch 내부 구조

클러스터 (Cluster)

여러 개의 노드가 네트워크로 연결된 것을 클러스터라고 한다.

즉, 클러스터는 노드의 잡합이며 하나 이상의 노드로 구성된다.

같은 서버나 네트워크망 내부에 있다하더라도, 클러스터명이 다르면 다른 클러스터로 실행되어 별개의 시스템으로 인식된다.

 

노드 (Node)

Elasticsearch의 기본 작동 단위이다.

노드는 Elasticsearch 서비스가 설치되어 실행되는 각 서버를 의미 한다.

노드들은 데이터를 저장하고, 클러스터의 일부로 동작하여 검색 및 인덱싱 작업 등을 수행한다.

 

인덱스 (Index)

RDB의 Row를 Elasticsearch에서는 도큐먼트(document)라고 부른다.

그리고 이 도큐먼트를 모아놓은 집합을 인덱스(Index)라고 한다. (RDB에서는 테이블)

인덱스는 아래 처럼 하나 이상의 샤드로 분할될 수 있다.

 

샤드 (Shard)

샤드는 Elasticsearch에서 데이터를 분산 저장하는 방법으로, 갹 샤드는 독립적인 "인덱스"라고 할 수 있으며 자체적으로 검색 가능하다. (Kafka와 파티션과 같은 의미)

샤딩(sharding)은 대용량 데이터를 여러 노드에 분산시켜 저장하고 처리하는 데 필요하며, 이로써 성능 향상과 확장성 등의 장점을 얻을 수 있다.

예를 들어 1TB 크기의 데이터가 있는데 단일 노드에서 다루기 어렵다면 이를 5개 샤드로 나누면 각각 200GB 크기의 작은 단위로 처리할 수 있게 되므로 성능 향상 및 관리 효율성 등이 올라간다.

단일 Elasticsearch 클러스터 내에서 샤딩된 각 부분은 서로 다른 노드에 위치할 수 있으므로 한 노드가 실패해도 다른 노드에서 해당 샤드와 연관된 작업을 계속 진행할 수 있다는 장점도 있다.

 

하지만 샤드의 개수만큼 cpu의 스레드를 사용 하기 때문에 샤드의 개수가 많아질수록 리소스를 많이 잡아먹게된다.

그렇기 때문에 데이터에 맞춰 샤드 개수를 적절히 설정해야 한다.

출처 : https://jaemunbro.medium.com/elastic-search-%EC%83%A4%EB%93%9C-%EC%B5%9C%EC%A0%81%ED%99%94-68062271fb64

 

복제본 (Replica)

데이터 손실 방지와 검색 성능 향상을 위해 샤드가 복제될 수 있다.

복제본(replica shard)은 원래 샤드에 대한 복사본이며, 원래 샤드(primary shard)가 실패할 경우 자동으로 대체될 수 있다.

 

---

Elasticsearch 장점

Schema less

Json 문서를 통해 데이터 검색을 수행하므로 스키마 개념이 없다.

로그 데이터 처럼 비구조화된 데이터는 스키마가 다이나믹하게 변할 수 있기 때문에 JSON 구조가 적합하다.

 

저장

방대한 양의 로그 데이터들을 RDB에 저장한다고 생각해보자.

RDB는 트랜잭션 처리와 데이터 일관성 유지에 중점을 두고 설계 되었기 때문에 무수히 생성되는 로그 데이터를 실시간으로 저장하는 것은 한계가 있을 수 있다.

대부분의 RDBMS는 단일 노드에서 실행지만 Elasticsearch는 처음부터 분산 시스템으로 설계되었다.

그렇기 때문에 데이터를 여러 노드에 분산 저장하고 처리 및 새로운 노드를 추가(수평 확장(Scale out))할 수 있고, 스키마리스(schema-less) 방식이므로, 비구조화된 대량 데이터도 유연하게 저장할 수 있다.

 

검색

로그 데이터는 구조화되어 있지 않고 비구조화된 텍스트로 이뤄져있다.

비구조화된 많은 로그 데이터들을 RDB에서 조회하려면 복잡한 텍스트를 검색하기 힘들뿐더러, 인덱싱과 같은 추가 작업이 요구되어 시스템 부하가 증가할 수 있다.

반면에 Elasticsearch는 전체 텍스트 검색에 최적화된 엔진(Lucene 기반)을 사용해 대용량 데이터에서도 빠르게 정보를 찾을 수 있다.

또한 모든 데이터를 역 색인 구조로 저장해 가공된 텍스트를 검색한다.

거의 실시간 검색으로 사용할 수 있기 때문에 보안 분석, 인프라 모니터링 같은 사용 사례에 적합하다.

📌 역인덱싱이란?
역색인은 특정 단어를 포함한 문서들을 저장해둬서 특정 단어를 찾을 때 저장된 문서 목록을 확인한다.
역색인 구조로 특정 단어를 찾을 때 문서 전체가 아닌 단어를 포함한 특정 문서의 위치를 찾기 때문에 빠르다.
예를들어서 "This is Dev Blog"라는 문장이 있다면 Elasticsearch는 "The", "is", "Dev", "Blog" 각각의 단어에 대해 해당 단어가 속한 문서의 ID를 인덱스에 저장한다.
따라서 사용자가 "Blog"라는 단어를 검색 요청하면 Elasticsearch는 "Blog"의 역인덱스 목록에서 겹치는 문서 ID를 찾아내고 해당 문서를 검색 결과로 반환하다.

 

데이터 구조 유연성

RDB에서는 스키마 변경이 필요한 경우에는 DDL 작업이 필요하며 이 작업은 리소스 소모가 크고 복잡하다.

반면에 Elasticsearch는 JSON 형식의 문서 기반 모델을 사용해 스키마 변경 없이도 다양한 형태의 데이터를 유연하게 저장할 수 있다.

 

가용성

자동 복제(replication)와 샤딩(sharding) 기능으로 인해, 하나 또는 여러 개의 노드가 실패해도 서비스 중단 없이 데이터 저장 및 검색 작업을 계속 할 수 있다.

 

---

Elasticsearch의 단점

완전한 실시간 X

빠르지만 완전한 실시간은 아니다. Near real-time이다.

Elasticsearch는 데이터 저장 시점에 해당 데이터를 인덱싱한다.

 

트랜잭션과 롤백 기능이 없다.

전체적인 클러스터의 성능 향상을 위해서 시스템적으로 비용 소모가 큰 롤백과 트랜잭션을 지원하지 않는다.

즉, 트랜잭션과 무결성이 중요한 데이터의 저장소로 사용하기에 적합하지 않다.

Elasticsearch가 DB의 기능도 하지만 메인 데이터베이스로 단독 사용하는 것은 권장되지 않는다.

엄격한 데이터 요구사항이 있는경우에는 RDB가 더 적합하다.

 

데이터 삭제 및 수정의 비효율성

Elasticsearch는 실시간 검색과 분석을 위해 설계되었다. 그렇기 때문에 데이터 삭제나 수정 작업은 상대적으로 비효율적이다.

(Elasticsearch 에서의 업데이트는 기존 문서를 삭제하고 다시 삽입하는 방식)

---

ELK (Elasticsearch / Logstash / Kibana) 란?

Elasticsearch, Logstash, Kibana 의 앞글자를 따서 ELK라고 부른다.

주로 ELK는 WAS의 흩어져 있는 로그를 한 곳으로 모으고, 원하는 데이터를 빠르게 검색한 뒤 시각화하여 모니터링하기 위해 사용한다.

각각의 ELK 기술들에 대해 알아보자.

 

Beats

여러 데이터들을 서버에서 다른 곳으로 전송하는 역할을 한다.

밑에서 설명하는 Logstash의 동작 과정과 유사해 직접 사용해본 차이점을 설명하자면,

Beats는 FileBeat라고도 많이 나와있는데 이름처럼 주로 로그파일의 변화를 감지해 logstash나 elasticsearch로 전달하는 역할을 한다고 볼 수 있다.

(필자는 콘솔의 특정 로그들을 전송한다면 logback 파일을 정의해 서비스의 로그를 logstash로 전달하고, 로그파일 전송이 필요하다면 Beats 추가하는 것이 적합하다고 생각한다.)

 

Logstash

Logstash는 실시간 파이프라인 기능을 가져 데이터를 수집하는 역할을 하며 크게 3가지 과정이 있다.

1. 입력(Input) : 데이터 저장소로 부터 데이터를 입력받는 작업

2. 필터(filter) : 데이터를 확장, 변경, 필터링 및 삭제 처리하는 가공 작업

3. 출력 (Output) : 위 두 과정을 거친 데이터를 elasticsearch로  전송

 

Elasticsearch

ELK 구조에서의 elasticsearch의 역할은 Logstash를 통해 수신된 데이터를 ElasticSearch에 저장하는 데이터 저장소 역할을 한다.

NoSQL 기반 데이터베이스이며 RDB와 다르게 트랜잭션 Rollback을 지원하지 않으나 검색 및 분석 성능이 뛰어나다.

 

Kibana

Elasticsearch에 저장된 데이터들을 모아서 시각화하는 역할을 한다.

kibana를 이용해 시각화하면 한눈에 데이터를 파악하여 분석할 수 있다.